Describe what this PR does

Fixes the first item of #6531: the RADOS lock that serializes fscrypt setup for encrypted volumes lives in the
default namespace of the metadata pool, while every other object Ceph-CSI creates for a CephFS cluster lives
in the configured RADOS namespace (cephFS.radosNamespace, default csi).

This PR places the lock in the RADOS namespace configured by cephFS.radosNamespace.

Is there anything that requires special attention

Is the change backward compatible?

Yes, I implemented a transitional legacy lock mechanism that keeps mixed-version deployments safe. This
mechanism makes nodes that include the changes of this PR try to get both the new lock (placed in
cephFS.radosNamespace) and the old lock (placed in the default RADOS namespace).

However, the "old lock" in the default RADOS namespace is not required in two cases. If the CephX capabilities
of the node cannot access the default namespace, the mount continues without it (such a deployment could never
stage an encrypted volume before this change, so no old nodeplugin can be holding the old lock). Volumes
without a RADOS namespace (static volumes) take only one lock, in the default namespace, because both locks
would be the same object. Any other failure to take the old lock fails the mount.

The legacy lock is marked with a TODO for removal once upgrades from releases that lock in the default
namespace are no longer supported.

Do you have any questions?

• Is protecting the rolling-upgrade edge case worth the code it takes? The core fix is the single
  SetNamespace() call. The rest of the PR exists to keep an old nodeplugin and an upgraded one serialized
  while updating. The serialization only matters when the same encrypted volume is staged on a non-updated
  ceph-csi instance and an updated ceph-csi instance at the same time. If that window is considered
  unimportant, the legacy lock can be dropped (together with the sentinel-error commit it depends on and its
  e2e check). Instead the upgrade documentation would warn operators not to start pods that mount encrypted
  volumes while the nodeplugin upgrade is running. Ceph-CSI cannot enforce this since a nodeplugin does not
  know that a rolling upgrade is in progress, and the legacy lock is exactly the mechanism that serializes the
  two sides. Avoiding the race would be left entirely to the operator.

• Is the e2e test's dependency on RADOS lock internals acceptable? The lock is released before
  NodeStageVolume returns, so the test can not observe it held. Instead it checks for the object that
  cls_lock leaves behind on unlock, which holds for every lock type except LOCK_EXCLUSIVE_EPHEMERAL. Should
  cls_lock ever stop leaving the object behind, or the fscrypt lock become ephemeral, the test breaks without
  any product regression. An e2e test was asked for in cephfs: cephFS.radosNamespace is not applied consistently #6531, so if this dependency is not acceptable, I would
  rework the check rather than drop it. However suggestions for a better way to observe the lock's namespace
  are welcome (I am unsure how to do it in a different manner).

Related issues

Part of #6531.

Future concerns

• Remove the transitional legacy lock once upgrades from releases that take the fscrypt lock in the default
  namespace are no longer supported (marked with a TODO in the code).

AI assistance: this code was developed with the help of an AI assistant (Claude). Each commit carries the
Assisted-by: Claude Code <noreply@anthropic.com> trailer, per AGENTS.md.

Checklist:

• Commit Message Formatting: Commit titles and messages follow
  guidelines in the developer
  guide.
• Reviewed the developer guide on Submitting a Pull
  Request
• Pending release
  notes
  updated with breaking and/or notable changes for the next major release.
• Documentation has been updated, if necessary.
• Unit tests have been added, if necessary.
• Integration tests have been added, if necessary.

CI job ordering.

Depends-on: #6497